Node Rejection

If any of the server nodes you have defined (and placed under Objects) cannot be accepted for inclusion in OPC server's address space, a NodeRejected Event is raised for every such node. This happens as part of the server startup, i.e. following the Start Method invocation.

Currently, the only reason for which the node can be rejected is when its name (the Name Property) is empty.

Operation Errors in Synchronous Operations

Most operation methods in OPC Wizard operate synchronously (the notable exception to this are the Start and Stop methods). Such methods report errors by throwing an exception, and the possible exceptions are listed in the .NET Assemblies Reference.

Operation Errors in Asynchronous Operations

The most important asynchronous operations in OPC Wizard are invoked by the Start Method and Stop Method on the EasyUAServer Class. Aside from asynchronous execution errors and usage errors, methods that invoke asynchronous operations do not throw any exceptions. Instead, the operation outcome is indicated through events that you can handle. In case of the Start and Stop methods, the EndpointStateChanged Event has this purpose (for more information, see OPC Wizard Operation Monitoring Services).

Conversion Errors

Because the OPC UA data type model, and the type model used by OPC Wizard (based on .NET) differ, the OPC Wizard needs to perform type conversions. The type conversions take place:

• After your code provides the data for OPC Read operation.
• Before the data used in OPC Write operation is consumed by your code.
• After your code updates the data for a data subscription (by calling its OnNext method).

The type conversion may fail - either because the source and destination types are in principle incompatible, or the conversion is not supported, or your code might have supplied an incorrect data (a type that cannot be converted). The conversion failure of course cannot stop the server from functioning. The OPC Wizard reports the conversion error internally, and the OPC UA client receives an error indication in form of a "Bad" status code.

The conversion error is handled analogically to Read, Write etc. requests in the node space, as described in Data Provision And Consumption Models. When a conversion error is detected, it always relates to a specific data variable. The virtual OnConversionError Method is called on the data variable. Its default implementation raises the ConversionError Event on the data variable. If the event is not handled, it optionally (depending on the PropagateConversionError Property) propagates to the ancestor levels, up to the server object.

If you want to capture the conversion errors and process them, you can do so by overriding OnConversionError Method, or adding an event handler to the ConversionError Event, at various levels. The handler is passed an instance of UADataVariableConversionErrorEventArgs Class. This object contains the "action" that caused the error (the Action Property, where the value is either Read, Write or Update), and the service result of the failed conversion (the ServiceResult Property).

The server object keeps has an internal global counter of conversion errors, and increments it automatically whenever a conversion error occurs. This counter (/Objects/Diagnostics/ConversionErrorCount variable) is visible to OPC clients and you can use it to diagnose whether the conversion errors are occurring in your server.

Exceptions in Event Handlers

Event handlers that you add to events on various OPC Wizard objects are not supposed to throw any exceptions (except for asynchronous execution errors and usage errors). If an exception is thrown anyway, the OPC Wizard handles it by creating an event log entry with information about the exception. For more information, see Component Event Logging.